33장. MCP가 등장한 이유

앞 장에서는 AI가 외부 도구를 사용한다는 것이 무엇인지 살펴보았다.

단순 챗봇은 사용자의 질문에 답변하는 구조다.
반면 도구 사용 AI는 문서, DB, API, Jira, GitHub, Slack 같은 외부 시스템을 사용해 필요한 정보를 찾고 작업을 보조할 수 있다고 했다.

이 구조는 강력하다.

AI가 문서를 검색하고, DB를 조회하고, PR을 분석하고, Jira 이슈를 정리할 수 있다면 개발팀의 반복 업무를 크게 줄일 수 있다.

하지만 동시에 문제가 생긴다.

도구마다 연결 방식이 다르다.
AI 도구마다 플러그인 방식도 다르다.
권한 관리 방식도 제각각이다.
어떤 도구는 파일을 읽고, 어떤 도구는 API를 호출하고, 어떤 도구는 DB를 조회한다.

AI가 외부 도구를 사용하는 시대가 되려면, AI와 도구를 연결하는 공통된 방식이 필요하다.

이런 배경에서 등장한 개념이 MCP다.

MCP는 Model Context Protocol의 줄임말이다.
말 그대로 AI 모델이 외부 맥락과 도구를 사용할 수 있도록 연결하는 프로토콜이다.

이번 장에서는 MCP가 왜 등장했는지, 기존 플러그인 방식에는 어떤 한계가 있었는지, MCP Client와 MCP Server는 무엇인지, MCP가 해결하려는 문제가 무엇인지 살펴본다.

1. AI가 외부 도구를 사용해야 하는 이유

LLM은 질문에 답변할 수 있다.

하지만 LLM이 모든 최신 정보를 알고 있는 것은 아니다.
회사 내부 문서도 알지 못한다.
우리 팀 Jira 이슈도 알지 못한다.
방금 올라온 GitHub PR도 알지 못한다.
운영 DB의 현재 상태도 알지 못한다.

그래서 사용자가 필요한 정보를 직접 붙여넣어야 한다.

예를 들어 다음과 같은 방식이다.

사용자:
아래 회의록을 요약해줘.

AI:
요약 결과를 제공합니다.

이 방식은 간단하다.
하지만 사용자가 매번 자료를 찾아서 붙여넣어야 한다.

문서가 길면 일부만 넣어야 한다.
최신 문서인지 직접 확인해야 한다.
Jira나 GitHub처럼 외부 시스템에 있는 정보는 사용자가 직접 복사해야 한다.

AI를 실무에 제대로 사용하려면 AI가 필요한 정보를 직접 가져올 수 있어야 한다.

예를 들어 다음과 같은 요청이 가능해야 한다.

이번 주 완료된 Jira 이슈를 요약해줘.

최근 병합된 PR 중 정산 관련 변경 사항을 찾아줘.

장애 대응 매뉴얼에서 DB 부하 대응 절차를 찾아줘.

이 프로젝트의 README와 API 문서를 읽고 구조를 설명해줘.

로컬 파일에서 설정 관련 문서를 찾아서 요약해줘.

이런 요청을 처리하려면 AI가 외부 도구를 사용할 수 있어야 한다.

- 파일 시스템 접근
- 문서 검색
- Jira 조회
- GitHub 조회
- Slack 검색
- DB 조회
- 사내 API 호출

AI가 외부 도구를 사용하면 답변의 범위가 넓어진다.

단순히 모델이 기억하는 지식이 아니라, 실제 업무 시스템의 최신 정보를 바탕으로 답변할 수 있다.

하지만 여기에는 연결 문제가 있다.

각 도구마다 API가 다르고, 인증 방식이 다르고, 데이터 형식이 다르다.
AI 도구가 외부 시스템을 매번 따로 연결해야 한다면 개발과 운영이 복잡해진다.

MCP는 이 문제를 줄이기 위해 등장했다.

2. 기존 플러그인 방식의 한계

AI가 외부 도구를 사용하는 방식은 MCP 이전에도 있었다.

대표적으로 플러그인 방식, 확장 프로그램 방식, 자체 API 연동 방식이 있었다.

예를 들어 어떤 AI 도구는 GitHub 플러그인을 제공할 수 있다.
어떤 도구는 Google Drive 연결 기능을 제공할 수 있다.
어떤 도구는 Slack 검색 기능을 별도로 만들 수 있다.

문제는 이런 방식이 도구마다 따로따로 만들어진다는 점이다.

예를 들어 AI 도구 A에서 GitHub를 연결하는 방식과, AI 도구 B에서 GitHub를 연결하는 방식이 다를 수 있다.

AI 도구 A
→ GitHub 전용 플러그인

AI 도구 B
→ GitHub 전용 커넥터

AI 도구 C
→ 별도 API 연동 코드 필요

같은 GitHub를 연결하는데도 AI 도구마다 구현이 달라진다.

반대로 하나의 AI 도구에서 여러 시스템을 연결하려면 시스템마다 별도 플러그인을 만들어야 한다.

AI 도구
→ GitHub 플러그인
→ Jira 플러그인
→ Slack 플러그인
→ Notion 플러그인
→ DB 플러그인
→ 파일 시스템 플러그인

처음에는 괜찮아 보인다.
하지만 연결할 도구가 많아질수록 관리가 어려워진다.

기존 플러그인 방식의 한계는 다음과 같다.

- AI 도구마다 플러그인 방식이 다르다
- 같은 외부 도구를 여러 AI 도구에 반복해서 연결해야 한다
- 인증과 권한 처리가 일관되지 않다
- 도구 목록을 AI가 표준 방식으로 발견하기 어렵다
- 입력과 출력 형식이 도구마다 다르다
- 보안 정책을 통일하기 어렵다
- 로컬 도구와 원격 도구 연결 방식이 다르다
- 사내 도구를 연결하려면 매번 별도 개발이 필요하다

예를 들어 사내에 배포 관리 시스템이 있다고 해보자.

AI 도구 A에서 쓰려면 A에 맞는 플러그인을 만들어야 한다.
AI 도구 B에서 쓰려면 B에 맞는 플러그인을 또 만들어야 한다.
IDE형 AI에서 쓰려면 또 다른 확장을 만들어야 할 수 있다.

이런 구조는 확장성이 떨어진다.

AI가 외부 도구를 많이 사용할수록, 공통된 연결 규칙이 필요해진다.

3. MCP의 기본 개념

MCP는 Model Context Protocol의 줄임말이다.

이름을 풀어보면 다음과 같다.

Model
→ AI 모델

Context
→ 모델이 답변을 만들 때 참고하는 외부 맥락

Protocol
→ 서로 통신하기 위한 약속

즉, MCP는 AI 모델이 외부 맥락과 도구를 사용할 수 있도록 연결하는 표준적인 약속이라고 볼 수 있다.

여기서 외부 맥락은 다양하다.

- 로컬 파일
- 코드 저장소
- 사내 문서
- DB 조회 결과
- 업무 도구 데이터
- API 응답
- 로그
- 설정 정보

MCP의 목표는 AI가 이런 외부 정보를 더 일관된 방식으로 사용할 수 있게 하는 것이다.

MCP를 아주 단순하게 표현하면 다음 구조다.

AI 애플리케이션
→ MCP Client
→ MCP Server
→ 외부 도구 또는 데이터

AI 애플리케이션은 사용자가 대화하는 곳이다.
예를 들어 AI IDE, 데스크톱 AI 앱, 채팅형 AI 도구가 될 수 있다.

MCP Client는 AI 애플리케이션 안에서 MCP Server와 통신하는 역할을 한다.

MCP Server는 실제 외부 도구나 데이터를 감싸서 AI가 사용할 수 있는 형태로 제공한다.

예를 들어 파일 시스템 MCP Server는 로컬 파일을 읽는 기능을 제공할 수 있다.
GitHub MCP Server는 PR 조회나 이슈 조회 기능을 제공할 수 있다.
DB MCP Server는 제한된 DB 조회 기능을 제공할 수 있다.

중요한 점은 AI가 외부 시스템을 직접 아는 것이 아니라, MCP Server가 제공하는 기능을 통해 접근한다는 것이다.

MCP란?
Model Context Protocol의 줄임말이다.
AI 애플리케이션이 외부 도구, 데이터, 문서, 파일 시스템과 연결될 수 있도록 정한 표준적인 통신 방식이다.

4. MCP Client와 MCP Server

MCP를 이해하려면 MCP Client와 MCP Server를 구분해야 한다.

MCP Client는 AI 애플리케이션 쪽에 있다.

예를 들어 사용자가 AI 코딩 도구를 열고 다음과 같이 말한다고 해보자.

이 프로젝트의 README와 docs 폴더를 읽고 구조를 설명해줘.

이 요청을 받은 AI 애플리케이션은 로컬 파일을 읽어야 한다.

이때 AI 애플리케이션 안의 MCP Client가 파일 시스템 MCP Server에 요청을 보낸다.

MCP Client:
docs 폴더의 파일 목록을 알려줘.

MCP Server:
다음 파일들이 있습니다.
- docs/api.md
- docs/deploy.md
- docs/auth.md

그다음 AI는 필요한 파일을 읽고 답변한다.

MCP Server는 외부 도구를 AI가 사용할 수 있게 제공하는 쪽이다.

예를 들어 다음과 같은 MCP Server가 있을 수 있다.

- 파일 시스템 MCP Server
- GitHub MCP Server
- Jira MCP Server
- Slack MCP Server
- DB 조회 MCP Server
- 사내 API MCP Server
- 문서 검색 MCP Server

MCP Server는 자신이 제공하는 기능을 MCP Client에게 알려준다.

예를 들어 파일 시스템 MCP Server는 다음 기능을 제공할 수 있다.

- 디렉터리 목록 조회
- 파일 읽기
- 파일 검색

DB MCP Server는 다음 기능을 제공할 수 있다.

- 특정 통계 조회
- 제한된 SELECT 실행
- 미리 정의된 리포트 조회

Jira MCP Server는 다음 기능을 제공할 수 있다.

- 이슈 검색
- 이슈 상세 조회
- 이슈 댓글 조회
- 이슈 생성
- 상태 변경

물론 쓰기 기능은 더 조심해야 한다.

MCP Server가 어떤 기능을 제공하느냐에 따라 AI가 할 수 있는 일이 달라진다.

그래서 MCP Server 설계가 중요하다.

AI가 위험한 기능을 호출하지 못하게 하려면, MCP Server 단계에서 기능과 권한을 제한해야 한다.

5. AI 도구 연결의 표준화

MCP가 해결하려는 핵심 문제 중 하나는 도구 연결의 표준화다.

기존에는 AI 도구마다 외부 도구 연결 방식이 달랐다.

예를 들어 어떤 AI 도구에서 파일을 읽으려면 A 방식으로 연결하고, 다른 AI 도구에서는 B 방식으로 연결해야 했다.

MCP를 사용하면 구조가 조금 달라진다.

외부 도구는 MCP Server 형태로 기능을 제공한다.
AI 애플리케이션은 MCP Client를 통해 MCP Server와 통신한다.

즉, 외부 도구가 AI 도구마다 따로 연결되는 것이 아니라, MCP라는 공통 규칙을 통해 연결된다.

단순화하면 다음과 같다.

기존 방식은 이렇다.

AI 도구 A → GitHub 전용 연동
AI 도구 B → GitHub 전용 연동
AI 도구 C → GitHub 전용 연동

MCP 방식은 이렇다.

AI 도구 A → MCP Client → GitHub MCP Server
AI 도구 B → MCP Client → GitHub MCP Server
AI 도구 C → MCP Client → GitHub MCP Server

이렇게 되면 같은 MCP Server를 여러 AI 도구에서 사용할 수 있다.

물론 실제 운영에서는 인증, 권한, 환경 설정 차이가 있다.
하지만 기본 개념은 외부 도구 연결을 재사용 가능하게 만드는 것이다.

사내 도구에서도 이 장점이 크다.

예를 들어 회사에 내부 장애 관리 시스템이 있다고 해보자.

기존 방식이라면 각 AI 도구마다 장애 관리 시스템 연동을 따로 만들어야 한다.

MCP 방식이라면 장애 관리 MCP Server를 만들고, MCP를 지원하는 AI 도구에서 사용할 수 있다.

이렇게 하면 사내 시스템을 AI에 연결하는 방식이 더 정리된다.

6. MCP가 해결하려는 문제

MCP가 해결하려는 문제는 단순히 “AI가 도구를 쓰게 하자”가 아니다.

더 정확히 말하면 AI와 외부 도구 사이의 연결 방식을 정리하려는 것이다.

MCP가 해결하려는 주요 문제는 다음과 같다.

첫째, 도구 연결 방식의 분산이다.

도구마다, AI 애플리케이션마다 연결 방식이 달라지면 관리가 어렵다.
MCP는 공통된 연결 방식을 제공해 이 문제를 줄이려 한다.

둘째, 도구 발견 문제다.

AI 애플리케이션은 어떤 도구를 사용할 수 있는지 알아야 한다.
MCP Server는 자신이 제공하는 기능을 Client에게 알려줄 수 있다.

예를 들어 이런 식이다.

이 MCP Server는 다음 도구를 제공합니다.

- searchIssues
- getIssueDetail
- createIssue
- addComment

AI는 이 목록을 보고 필요한 도구를 선택할 수 있다.

셋째, 입력과 출력 형식 문제다.

외부 도구마다 API 형식이 다르면 AI가 사용하기 어렵다.
MCP는 도구 호출과 결과 반환을 일정한 구조로 다룰 수 있게 한다.

넷째, 로컬과 원격 도구 연결 문제다.

AI가 사용할 도구는 원격 API만 있는 것이 아니다.

로컬 파일 시스템, 로컬 개발 서버, 로컬 코드 저장소도 사용할 수 있어야 한다.
MCP는 이런 로컬 도구 연결에도 활용될 수 있다.

다섯째, 사내 도구 확장 문제다.

회사마다 내부 시스템이 다르다.

- 배포 관리 시스템
- 장애 관리 시스템
- 회원 관리 시스템
- 운영툴
- 로그 조회 시스템
- 정산 검증 시스템

이런 사내 도구를 AI에 연결하려면 표준적인 서버 형태로 제공하는 것이 좋다.

MCP Server는 이런 사내 도구를 AI가 사용할 수 있는 형태로 감싸는 역할을 할 수 있다.

7. MCP가 모든 자동화를 해결하는 것은 아니다

MCP는 유용한 개념이다.

하지만 MCP가 모든 자동화 문제를 해결해주는 것은 아니다.

MCP는 AI와 외부 도구를 연결하는 방식이다.
연결이 쉬워진다고 해서 자동으로 안전해지는 것은 아니다.

예를 들어 DB MCP Server를 만들었다고 해보자.

AI가 DB를 조회할 수 있게 되었다.

하지만 다음 문제는 여전히 남아 있다.

- 어떤 테이블을 조회할 수 있는가
- 개인정보 컬럼은 어떻게 처리하는가
- 쿼리 부하는 어떻게 제한하는가
- 사용자가 권한 없는 데이터를 볼 수 없는가
- 조회 로그는 남는가
- 쓰기 쿼리는 차단되는가

MCP는 연결 통로를 제공할 뿐이다.
보안 정책과 권한 설계는 별도로 해야 한다.

또 Jira MCP Server를 만들었다고 해보자.

AI가 Jira 이슈를 생성할 수 있다.

하지만 다음 문제는 여전히 남아 있다.

- AI가 임의로 이슈를 생성해도 되는가
- 생성 전 사람 승인이 필요한가
- 잘못 생성된 이슈는 어떻게 처리하는가
- 어떤 프로젝트에만 생성할 수 있는가
- 담당자와 우선순위를 AI가 정해도 되는가
- 생성 로그는 남는가

MCP는 자동화의 기반이 될 수 있다.
하지만 업무 정책을 대신 정해주지는 않는다.

따라서 MCP를 사용할 때는 다음을 구분해야 한다.

MCP가 해주는 것:
- AI와 도구 연결 방식 제공
- 도구 목록 제공
- 도구 호출 구조 제공
- 결과 반환 구조 제공

MCP가 자동으로 해주지 않는 것:
- 회사 보안 정책 결정
- 사용자 권한 설계
- 민감 정보 필터링
- 승인 프로세스 설계
- 장애 대응 설계
- 비용 관리
- 운영 로그 정책

MCP를 도입할 때 가장 위험한 생각은 이것이다.

MCP로 연결하면 알아서 안전하게 자동화되겠지.

그렇지 않다.

MCP는 도구를 연결하기 쉽게 만든다.
그래서 더더욱 어떤 도구를 어떤 권한으로 연결할지 신중해야 한다.

8. MCP와 API 서버의 차이

MCP Server를 처음 보면 API 서버와 비슷하게 느껴질 수 있다.

실제로 둘은 닮은 점이 있다.

API 서버도 외부에서 요청을 받고 기능을 수행한다.
MCP Server도 AI 애플리케이션의 요청을 받고 기능을 제공한다.

하지만 목적이 조금 다르다.

일반 API 서버는 보통 애플리케이션이나 프론트엔드가 사용하기 위해 만든다.

예를 들어 웹 프론트엔드가 사용자 정보를 조회하려고 API를 호출한다.

Frontend
→ User API Server
→ DB

MCP Server는 AI가 사용할 수 있는 도구를 제공하기 위해 만든다.

AI Application
→ MCP Client
→ MCP Server
→ 외부 시스템

MCP Server는 AI가 이해하고 선택할 수 있도록 기능을 설명해야 한다.
어떤 도구가 있고, 어떤 입력이 필요하고, 어떤 결과를 반환하는지 제공해야 한다.

일반 API는 사람이 문서를 보고 사용하는 경우가 많다.
MCP Server는 AI가 도구 목록과 설명을 보고 사용할 수 있어야 한다.

비교하면 다음과 같다.

MCP Server를 만들 때 기존 API 서버를 그대로 노출하는 것은 위험할 수 있다.

AI에게 모든 API를 그대로 열어주는 것이 아니라, AI가 사용해도 되는 기능만 MCP Server로 감싸는 것이 좋다.

예를 들어 운영 API에 다음 기능이 있다고 해보자.

- 사용자 조회
- 사용자 차단
- 사용자 삭제
- 포인트 지급
- 결제 취소

이 API를 그대로 AI에게 열면 위험하다.

대신 처음에는 읽기 기능만 MCP Server로 제공할 수 있다.

- 사용자 상태 조회
- 최근 제재 이력 조회
- 결제 상태 조회

쓰기 기능은 별도 승인 구조가 준비된 뒤 제한적으로 제공하는 것이 안전하다.

9. MCP와 RAG의 차이

MCP를 RAG와 혼동할 수도 있다.

둘 다 AI가 외부 정보를 활용한다는 점에서 비슷해 보인다.

하지만 역할이 다르다.

RAG는 Retrieval-Augmented Generation의 줄임말이다.
앞에서 다룬 것처럼, 질문과 관련된 문서를 검색해서 AI 답변에 참고하게 하는 구조다.

예를 들어 사내 문서를 벡터DB에 넣고, 사용자의 질문과 관련된 문서를 찾아 AI에게 전달한다.

사용자 질문
→ 문서 검색
→ 관련 문서 조각 반환
→ AI 답변 생성

RAG는 주로 지식 검색과 문서 기반 답변에 강하다.

반면 MCP는 AI가 외부 도구를 사용할 수 있게 하는 연결 구조다.

MCP를 통해 문서 검색 도구를 제공할 수도 있고, DB 조회 도구를 제공할 수도 있고, Jira 이슈 조회 도구를 제공할 수도 있다.

즉, RAG는 주로 “관련 문서를 찾아 답변하는 방식”이고, MCP는 “AI가 도구를 사용할 수 있게 연결하는 방식”이다.

비교하면 다음과 같다.

둘은 경쟁 관계가 아니다.

함께 사용할 수 있다.

예를 들어 문서 검색 MCP Server가 내부적으로 RAG를 사용할 수 있다.

AI
→ MCP Client
→ 문서 검색 MCP Server
→ 벡터DB 검색
→ 관련 문서 반환
→ AI 답변

이 경우 MCP는 연결 방식이고, RAG는 문서를 검색하는 내부 구현 방식이다.

이 구분을 이해하면 MCP를 더 명확히 볼 수 있다.

MCP는 RAG를 대체하는 개념이 아니라, AI가 여러 도구를 사용할 수 있게 하는 더 넓은 연결 구조에 가깝다.

10. MCP와 에이전트의 관계

MCP를 이야기할 때 에이전트도 함께 언급되는 경우가 많다.

에이전트는 사용자의 목표를 달성하기 위해 여러 단계를 계획하고 도구를 사용하는 AI 구조다.

예를 들어 사용자가 이렇게 요청한다.

이번 주 정산 관련 변경 사항을 정리하고,
위험해 보이는 PR이 있으면 알려줘.

에이전트는 다음 단계를 구성할 수 있다.

1. 이번 주 병합된 PR 조회
2. 정산 관련 키워드가 있는 PR 필터링
3. 각 PR diff 분석
4. DB 변경 여부 확인
5. 테스트 누락 후보 정리
6. 위험 PR 요약

이때 에이전트가 도구를 사용하려면 연결 방식이 필요하다.

여기서 MCP가 활용될 수 있다.

에이전트
→ GitHub MCP Server로 PR 조회
→ Jira MCP Server로 이슈 조회
→ 문서 MCP Server로 정산 규칙 문서 검색
→ 결과 종합

즉, 에이전트는 “작업을 계획하고 수행하는 구조”에 가깝고, MCP는 “도구를 연결하는 방식”에 가깝다.

에이전트가 MCP를 사용할 수 있다.

하지만 MCP가 있다고 해서 자동으로 에이전트가 되는 것은 아니다.

단순히 AI가 파일 하나를 읽기 위해 MCP Server를 호출하는 것도 MCP 사용이다.
여러 도구를 조합해 목표를 수행하면 에이전트적 사용에 가까워진다.

비교하면 다음과 같다.

에이전트를 만들 때는 MCP가 유용하다.
하지만 에이전트에는 추가 설계가 필요하다.

- 작업 계획
- 중간 결과 저장
- 실패 시 중단
- 재시도
- 사람 승인
- 로그 추적
- 권한 제한

MCP는 도구 연결을 돕는다.
에이전트의 판단과 실행 흐름까지 자동으로 안전하게 만들어주지는 않는다.

11. MCP 도입이 유용한 경우

MCP는 모든 상황에 필요한 것은 아니다.

간단한 AI 기능에는 MCP 없이도 충분할 수 있다.

예를 들어 사용자가 입력한 문장을 요약하는 기능이라면 MCP가 필요 없다.

사용자 입력
→ AI 요약
→ 결과 반환

문서 하나를 업로드해서 요약하는 기능도 MCP 없이 구현할 수 있다.

하지만 다음과 같은 경우에는 MCP를 검토할 만하다.

- 여러 AI 도구에서 같은 외부 도구를 사용해야 한다
- 로컬 파일이나 코드 저장소를 AI와 연결하고 싶다
- 사내 API를 AI 도구에서 재사용 가능한 방식으로 제공하고 싶다
- Jira, GitHub, Slack 같은 업무 도구를 AI가 사용해야 한다
- AI 에이전트가 여러 도구를 조합해야 한다
- 도구 목록과 호출 방식을 표준화하고 싶다
- 도구 연결을 AI 애플리케이션과 분리하고 싶다

예를 들어 개발팀에서 AI 코딩 도구, 문서 검색 AI, 코드 리뷰 AI를 함께 쓴다고 해보자.

각각이 GitHub에 접근해야 한다면, GitHub 연동을 각 도구마다 따로 만드는 것보다 GitHub MCP Server를 두고 재사용하는 방식이 더 나을 수 있다.

또 사내 배포 시스템을 AI와 연결하고 싶다면, 배포 시스템 API를 바로 AI에게 열기보다 MCP Server로 감싸서 기능을 제한할 수 있다.

허용:
- 배포 상태 조회
- 최근 배포 이력 조회
- 배포 실패 로그 조회

제한:
- 배포 실행
- 롤백 실행
- 운영 설정 변경

이렇게 하면 AI가 사용할 수 있는 범위를 명확히 할 수 있다.

12. MCP 도입이 오히려 과한 경우

반대로 MCP가 과한 경우도 있다.

모든 AI 기능에 MCP를 붙일 필요는 없다.

예를 들어 다음 기능은 MCP 없이도 충분할 수 있다.

- 사용자가 입력한 텍스트 요약
- 단일 문서 업로드 후 요약
- 정해진 프롬프트 기반 답변 생성
- 간단한 FAQ 챗봇
- 고정된 API 하나만 호출하는 내부 기능
- 외부 도구 연결이 필요 없는 코드 생성 보조

MCP를 도입하면 구조가 늘어난다.

AI 애플리케이션
MCP Client
MCP Server
외부 시스템
권한 관리
로그
배포
모니터링

즉, 운영해야 할 구성 요소가 늘어난다.

단순 기능에 MCP를 넣으면 오히려 복잡도가 증가할 수 있다.

기술을 도입할 때는 항상 질문해야 한다.

이 기능에 MCP가 꼭 필요한가?

단순 API 호출로 충분하지 않은가?

여러 AI 도구에서 재사용할 필요가 있는가?

도구 목록을 표준화해야 하는가?

권한과 로그를 MCP Server 단위로 관리하는 것이 이득인가?

MCP는 좋은 도구지만, 모든 문제의 기본값은 아니다.

실무에서는 단순한 구조로 충분한 경우도 많다.

처음부터 MCP를 도입하기보다, 외부 도구 연결이 늘어나고 복잡도가 커질 때 검토하는 방식이 현실적이다.

13. 사내 시스템과 MCP

MCP의 실무적 가치는 사내 시스템과 연결할 때 특히 커질 수 있다.

회사의 주요 정보는 공개 인터넷에 없다.

- 내부 개발 문서
- 장애 대응 기록
- 운영 매뉴얼
- Jira 이슈
- GitHub Enterprise 저장소
- 배포 시스템
- 모니터링 시스템
- 관리자 도구
- 정산 검증 시스템
- 고객 문의 기록

이런 시스템을 AI가 활용하려면 연결 방식이 필요하다.

하지만 사내 시스템은 회사마다 다르다.
외부 AI 서비스가 기본으로 제공하는 커넥터만으로는 부족할 수 있다.

이때 MCP Server를 사내 시스템 앞에 둘 수 있다.

예를 들어 정산 검증 시스템이 있다고 해보자.

AI에게 정산 검증 DB를 직접 열어주는 것은 위험하다.

대신 정산 검증 MCP Server를 만들 수 있다.

이 서버는 제한된 기능만 제공한다.

- 특정 기간 정산 요약 조회
- 정산 오류 후보 조회
- 미처리 정산 건수 조회
- 정산 배치 실행 이력 조회

반대로 다음 기능은 제공하지 않는다.

- 정산 금액 수정
- 정산 상태 강제 변경
- 정산 데이터 삭제
- 수동 지급 실행

이렇게 하면 AI가 필요한 정보를 조회할 수 있으면서도 위험한 작업은 차단할 수 있다.

사내 시스템을 MCP로 연결할 때는 다음을 고려해야 한다.

- 어떤 기능을 제공할 것인가
- 읽기 전용으로 시작할 것인가
- 쓰기 작업은 승인 구조가 있는가
- 사용자 권한을 어떻게 반영할 것인가
- 민감 정보는 어떻게 마스킹할 것인가
- 호출 로그는 어디에 남길 것인가
- 실패 시 어떻게 응답할 것인가
- 운영 시스템에 부하를 주지 않는가

MCP Server는 단순 연결 코드가 아니다.

AI가 사내 시스템을 안전하게 사용하도록 만드는 경계선 역할을 한다.

14. MCP를 도입할 때 먼저 정해야 할 것

MCP를 도입하기 전에 먼저 정해야 할 것들이 있다.

첫째, 목적이다.

MCP를 왜 도입하려는지 명확해야 한다.

- 문서 검색을 위해서인가
- 코드 분석을 위해서인가
- Jira 업무 정리를 위해서인가
- 운영 도구 조회를 위해서인가
- 에이전트 자동화를 위해서인가

목적이 불명확하면 MCP Server가 불필요하게 커진다.

둘째, 도구 범위다.

처음부터 많은 기능을 제공하면 위험하다.

예를 들어 Jira MCP Server를 만든다면 처음에는 읽기 기능만 제공할 수 있다.

- 이슈 검색
- 이슈 상세 조회
- 댓글 조회

나중에 필요하면 쓰기 기능을 추가한다.

- 이슈 초안 생성
- 댓글 등록
- 상태 변경

셋째, 권한이다.

AI가 어떤 사용자 권한으로 도구를 호출하는지 정해야 한다.

- 공용 계정인가
- 사용자별 권한을 반영하는가
- 팀 단위 권한인가
- 읽기와 쓰기 권한이 분리되어 있는가

넷째, 승인 구조다.

쓰기 작업을 제공한다면 승인 절차가 필요하다.

AI가 초안 작성
→ 사용자 확인
→ 승인
→ 실행
→ 로그 저장

다섯째, 로그다.

모든 도구 호출은 추적 가능해야 한다.

- 누가 호출했는가
- 어떤 도구를 호출했는가
- 어떤 입력값을 사용했는가
- 결과가 무엇인가
- 실패했는가
- 승인자가 누구인가

여섯째, 실패 처리다.

도구 호출이 실패하면 AI가 추측으로 답하지 않도록 해야 한다.

Jira 조회에 실패했습니다.
현재 정보만으로는 완료 이슈를 확정할 수 없습니다.

이렇게 명확히 실패를 알려야 한다.

MCP 도입은 기술 구현보다 정책 설계가 먼저다.

15. MCP를 처음 도입할 때 추천하는 순서

MCP를 처음 도입한다면 낮은 위험 영역부터 시작하는 것이 좋다.

추천하는 순서는 다음과 같다.

1단계: 로컬 파일 읽기 MCP
2단계: 개발 문서 검색 MCP
3단계: GitHub 읽기 전용 MCP
4단계: Jira 읽기 전용 MCP
5단계: 로그 또는 모니터링 조회 MCP
6단계: 제한된 사내 API 조회 MCP
7단계: 승인 기반 쓰기 도구
8단계: 에이전트 구조와 연결

처음부터 DB 쓰기나 배포 실행을 연결하면 위험하다.

처음에는 읽기 중심으로 시작해야 한다.

예를 들어 로컬 파일 읽기 MCP를 사용하면 AI가 프로젝트 문서를 읽고 설명할 수 있다.

이 프로젝트의 docs 폴더를 읽고 인증 구조를 설명해줘.

개발 문서 검색 MCP를 만들면 사내 문서 검색을 할 수 있다.

AI 보안 가이드라인에서 코드 외부 전송 관련 기준을 찾아줘.

GitHub 읽기 전용 MCP를 만들면 PR 요약이 가능하다.

이번 주 병합된 PR 중 관리자 기능 관련 변경을 정리해줘.

Jira 읽기 전용 MCP를 만들면 업무 정리가 가능하다.

이번 달 완료된 플랫폼개발1팀 이슈를 카테고리별로 정리해줘.

이런 읽기 작업에서 신뢰가 쌓이면, 그다음 승인 기반 쓰기 작업으로 확장할 수 있다.

이 회의록을 바탕으로 Jira 이슈 초안을 만들어줘.
내가 승인하면 등록해줘.

중요한 것은 단계적으로 확장하는 것이다.

MCP는 연결을 쉽게 해주지만, 연결할수록 위험도 함께 커진다.

16. 실무 예시: GitHub MCP Server를 생각해보기

GitHub MCP Server를 만든다고 가정해보자.

이 서버가 제공할 수 있는 기능은 다양하다.

읽기 기능은 다음과 같다.

- 저장소 목록 조회
- PR 목록 조회
- PR diff 조회
- 커밋 목록 조회
- 이슈 조회
- 특정 파일 읽기
- 브랜치 목록 조회

쓰기 기능은 다음과 같다.

- PR 댓글 작성
- 이슈 생성
- 라벨 추가
- 리뷰 요청
- 브랜치 생성
- 파일 수정
- PR 생성

처음부터 모든 기능을 제공하면 위험하다.

AI가 파일을 수정하거나 PR을 생성할 수 있게 되면 영향이 커진다.

처음에는 읽기 기능만 제공하는 것이 안전하다.

허용:
- PR 목록 조회
- PR diff 조회
- 이슈 조회
- 특정 파일 읽기

제한:
- 파일 수정
- 브랜치 생성
- PR 생성
- PR 병합
- 라벨 변경
- 권한 변경

그리고 읽기 기능도 권한을 제한해야 한다.

사용자가 접근할 수 있는 저장소만 조회해야 한다.
민감한 파일은 읽지 못하게 해야 한다.

예를 들어 다음 파일은 제한할 수 있다.

- .env
- secret.yml
- private.key
- credentials.json
- 운영 설정 파일

AI에게 PR diff를 제공할 때도 제외 규칙이 필요하다.

- 대용량 lock 파일 제외
- 자동 생성 파일 제외
- minify 파일 제외
- 인증키나 비밀 정보가 포함된 파일 제외

이렇게 제한된 GitHub MCP Server만으로도 많은 일을 할 수 있다.

- PR 요약
- 변경 영향도 후보 정리
- 테스트 누락 후보 확인
- 코드 리뷰 보조
- 릴리즈 노트 초안 작성

쓰기 기능은 나중에 추가한다.

예를 들어 PR 댓글 작성 기능을 추가한다면 승인 구조를 둔다.

AI가 댓글 초안 작성
→ 사용자가 확인
→ 승인
→ PR 댓글 등록

이 방식이 안전하다.

17. 정리

MCP는 AI가 외부 도구와 데이터를 사용할 수 있도록 연결하는 프로토콜이다.

AI가 실무에서 더 유용해지려면 외부 정보를 사용할 수 있어야 한다.
회사 문서, 로컬 파일, GitHub PR, Jira 이슈, DB 조회 결과, 사내 API 같은 정보는 모델이 기본적으로 알고 있지 않다.

기존 플러그인 방식은 도구마다, AI 애플리케이션마다 연결 방식이 달랐다.
연결할 도구가 늘어날수록 개발과 운영이 복잡해졌다.

MCP는 이런 문제를 줄이기 위해 AI와 외부 도구 사이의 공통 연결 방식을 제공하려는 개념이다.

MCP 구조에서는 AI 애플리케이션이 MCP Client를 통해 MCP Server와 통신한다.
MCP Server는 파일, 문서, DB, API, 업무 도구 같은 외부 기능을 AI가 사용할 수 있는 형태로 제공한다.

하지만 MCP가 모든 문제를 해결해주는 것은 아니다.

MCP는 도구 연결을 쉽게 해준다.
하지만 권한, 보안, 승인, 로그, 민감 정보 보호, 장애 대응은 별도로 설계해야 한다.

MCP를 안전하게 도입하려면 다음 원칙이 필요하다.

- 목적을 먼저 정한다
- 읽기 기능부터 시작한다
- 쓰기 기능은 승인 구조를 둔다
- 사용자 권한을 반영한다
- 민감 정보는 AI 입력으로 들어가지 않게 한다
- 도구 호출 로그를 남긴다
- 고위험 작업은 AI 단독 실행을 금지한다
- MCP Server가 제공하는 기능을 최소화한다
- 단계적으로 확장한다

MCP는 AI 자동화의 만능 해결책이 아니다.

하지만 AI와 외부 도구 연결이 늘어나는 환경에서는 중요한 기반 기술이 될 수 있다.

다음 장에서는 MCP의 기본 구조를 더 구체적으로 살펴본다.
Resource, Tool, Prompt, Transport, JSON-RPC 같은 개념을 하나씩 정리하면서 MCP가 실제로 어떤 구성으로 동작하는지 알아본다.

33장 핵심 요약